The present invention relates to communications networks. More particularly, and not by way of limitation, the present invention is directed to a system and method of Quality of Service (QoS) enablement for Over The Top (OTT) Applications in a telecommunications network.
With the increased popularity and enhanced services available on the Internet, a wide variety of OTT service providers such as Google®, Skype®, Vonage®, Facebook®, etc. have established a large base of subscribers. This phenomenon has made “bit pipes” out of the carriers, which removes service carriers from lucrative revenue opportunities in the services domain.
Today's service carriers prefer to be a part of the value chain by utilizing their assets (i.e., subscriber base, network components etc.). However, a relationship between the carriers and OTT service providers has not been forthcoming due to a lack of technical and business solutions that can merge their independent assets with their subscriber bases.
The current solution does not allow the OTT service providers to deliver their applications over the QoS-based communication channels. In this specific case, the current QoS request sent by the OTT service providers to the carriers does not have enough information for the carriers to identify the specific user with the QoS needs. This is because the request from the OTT service provider contains only the user's IP address without any other information. Typically the IP address associated with the user that arrives from the OTT service providers to the carriers' network undergoes a translation process in the Network Address Translation (NAT) function. This makes it difficult to uniquely associate the IP address to a user by the time a QoS request (from the OTT service providers) is received by the carriers' policy enforcement server, thus rendering it impossible for the carriers' network to apply the QoS to that specific user.
FIG. 1 is a simplified block diagram of an existing telecommunications system 10 illustrating the problem of IP address to user identity association. The telecommunications network includes a third party Application Server (AS), the Internet 14, a Network Address Translation (NAT) 16, a managed Internet Protocol (IP) network 18 and a Policy and Charging Rules Function (PCRF) 20. In this example, there are three zones, each having a User Equipment (UE). Zone one includes a Packet Data Network (PDN) Gateway (PGW) 30, a plurality of enhanced Node B (eNB) 32 and 34, and a UE 36 operating in a 4th Generation (4G) Radio Access Network (RAN) 38. Zone two includes a PDN GW 40, a plurality of eNB 42 and 44, and a UE 46 operating in a 4G RAN 48. Zone three includes a PDN GW 50, a plurality of eNB 52 and 54, and a UE 56 operating in a 4G RAN 58. In one example, the three different UEs 36, 46, and 56 are in separate zones. However, in this example, each UE has the same private IP address (e.g., 10.1.1.12). While accessing the Internet 14, the NAT 16 assigns each UE the same public IP address (e.g., 135.12.1.1), but with different port numbers. The UE 36 may initiate an IP-based application (e.g., Hyper Text Transfer Protocol (HTTP)) session with the third party AS 12. In response, the third party AS 12 sends a Policy Control message, such as an Rx message, to the PCRF 20. The PCRF 20 receives the Policy Control message with the UE 36's private IP address (i.e., 10.1.1.12). The PCRF is unable to resolve the IP address to a specific UE. Thus, a QoS request is unable to be sent or fulfilled.